跳到主要内容

Aurisper 产品需求与策划文档 (v1.0 收敛版) test auto deploy 2026 0106

🛑 版本发布说明 (Release Note)

  • 发布目标：v1.0 MVP (Minimum Viable Product)
  • 软件上线死线：2026 年 1 月 16 日
  • 硬件发布时间：2026 年 3 月 (Aurisper Pin)
  • 需求收敛原则：
    • 本文档作为 v1.0 版本的软件需求收敛基准。
    • v1.0 核心范围：聚焦于软件端的“极致准确率”、“隐私第一”及“Apple 生态独占”体验。
    • 硬件功能范围：v1.0 软件不需要支持 Aurisper Pin 的硬件连接与专属算法。第 11 章关于硬件的内容仅作为功能扩展说明和未来架构参考，不计入 v1.0 开发验收标准。
    • 平台发布策略：v1.0 仅发布 macOS 版本。iOS 版本将在 macOS 版本上线并稳定运行后，再纳入后续开发计划。本文档中关于 iOS 的部分仅作为交互统一性的参考，不作为首发交付内容。

1. 产品概述与定位 (Product Overview)​

  • 软件名字：Aurisper
  • 核心三原则 (Core Principles)：
    • 极简无感 (Foolproof & Seamless)：傻瓜式使用，用户不需要学习软件如何操作，打开即可用。
    • 隐私至上 (Privacy Paramount)：最大化隐私设计，保护用户数据是不可逾越的红线。
    • 极致准确 (Extreme Precision)：在上述基础上，通过技术手段实现语音转文字的极高准确率。
  • 用户场景：极致纯粹的语音输入 (Pure Voice Dictation)
    • 单一功能：仅专注“语音转文字输入”，剔除翻译、会议纪要、笔记管理等功能。
    • 单一对象：仅关注说话人（当前用户）一个人。不处理多人对话，不提供会议区分说话人（Diarization）功能。
    • 忠实转录 (Verbatim Transcription)：只做搬运工，不做润色师。
      • 不美化：即使是用户的口误、重复或语法错误，也忠实还原为文字。绝不进行 AI 语义美化、润色或自动“纠错”改写。
      • 核心目标：在 Apple 生态各设备及复杂声学环境下，实现极度准确的声文转换。确保每一个字都精准对应用户的发音，而非 AI 猜测的“正确意图”。
    • 严格边界 (Strict Boundary)：
      • 不存储：文字上屏到目标输入框后，系统内存即刻释放，绝不保存任何历史记录或文档。
      • 不处理：不对生成的文字进行摘要、提取关键词或语义分析。
      • 不利用：绝不利用用户的文字内容进行后续的数据挖掘或云端训练。
  • 体验特征：
    • 用户无感 (Seamless Usage)：启动快、输入流、修正少，用户在使用过程中几乎感觉不到工具的存在。
    • 无感训练 (Senseless Training)：
      • 自动化：后台自动按照规则和模型进行优化，用户无需手动干预配置。
      • 阶段性：只需在初期集中训练一段时间，后续即可实现完全脱网的高精度识别。
  • 技术铁律：极大化本地运行。数据坚决不上网，保持极度私有化状态。
  • 解决的问题：用户输入可以用语音输入，提升传统打字输入的速度 3-4 倍。
  • 技术趋势：在 AI 时代下，和 AI 的交互越来越多，会爆发式增长。AI 必须要把语音转成文字，才能执行或者理解如何回答，进行交互。

2. 平台与硬件支持 (Platform & Hardware Support)​

2.1 支持平台​

  • 用户支持的平台：macOS (v1.0 首发)，iOS (后续规划)
  • 生态独占性 (Apple Exclusive)：
    • 只做 Apple 平台：明确不开发 Windows、Android 或 Linux 版本。
    • 深度优化：放弃跨平台兼容性，旨在深度挖掘 Apple 软硬件生态（如 Apple Silicon NPU、Core Audio、Metal）的性能潜力，确保在 Apple 设备上实现无可比拟的响应速度和能效比。
  • macOS 支持的版本：待确定 (建议 v1.0 支持 macOS 14+)
  • iOS 支持的版本：待确定 (暂缓开发，待 macOS 稳定后启动)

2.2 支持硬件​

  • 计算机：MacBook, 平台台式机 (Mac mini, Mac Studio, iMac)
  • 移动设备：iPhone, iPad (后续支持)
  • 其他 Apple 硬件：待确定 (可能包含 Apple Watch 或 Vision Pro)

3. 使用场景与交互设计 (User Scenarios & Interaction)​

3.1 macOS 端使用场景​

  • 触发方式：用户按下 FN 键，开始语音输入。
  • 输入位置：在任意文本输入框，光标所在位置开始监听麦克风输入。
  • 输出表现：
    • 智能分段输出：在说话过程中，文字并非逐字跳出，而是基于智能规则（见 4.4）进行缓冲，通常在累积 20-30 个词 时批量平滑上屏。
    • 半流式输出：文本或者文字输出介于流式（实时逐字）和非流式（整句输出）之间。
    • 松开 FN 键，停止输入。
    • 状态反馈：悬浮球漂移。按下按键时，悬浮球飞至光标处并呈现呼吸态；松开按键时，悬浮球飞回初始位置。（详见 3.3 节）
  • 待定事项：
    • 是否要支持其他键的定义（需讨论）。
    • 需要支持第三方键盘的输入（需测试，或定义兼容清单，或进行 QA）。

💡 扩展解释：半流式 (Semi-streaming)

  • 原意：介于“蹦字”和“整句上屏”之间。
  • 扩展：完全流式（实时上屏）虽然反馈快，但频繁变动（Flicker）会干扰用户视线；非流式（说完再转）延迟感太强。半流式通常指在用户停顿或语义相对完整（10-20字）时才批量上屏，这样既能保证用户知道系统在工作，又能利用更多上下文信息提高准确率，减少用户看到的“纠错跳变”。

3.2 iOS 端使用场景 [Roadmap - Future]​

注：此模块暂不计入 v1.0 开发范围，仅作未来规划参考。

  • 系统定位：在操作系统层面，是一个第三方输入法。
  • 操作流程：
    • 在键盘列表中切换到 Aurisper。
    • 点击输入操作/按键，开始监控麦克风进行语音输入。
    • 过程中输出方式和 macOS 保持一致（半流式）。
    • 点击停止，停止输入。

3.3 用户交互设计 (UI/UX)​

  • 核心形态：智能悬浮球 (Smart Floating Orb)
    • 初始位置：APP 启动后，在屏幕右侧边缘中间显示一个带 Logo 的半透明悬浮球，表示程序已就绪。
    • 做减法 (Less is More)：取消顶部菜单栏 (Menu Bar) 图标设计。
      • 原因：避免在低分辨率屏幕或刘海屏设备上被隐藏；防止在图标拥挤的菜单栏中难以寻找；减少作为“后台辅助工具”对用户注意力的分散。
  • 动态交互逻辑 (Motion & Feedback)
    • 漂移跟随 (Drift & Follow)：
      • 当用户按下 FN 键（开始输入）时，悬浮球从屏幕右侧迅速漂移至当前鼠标光标/输入焦点的旁边。
    • 呼吸状态 (Breathing State)：
      • 在输入过程中，悬浮球呈现呼吸动效（律动的光晕或大小变化），直观反馈“正在聆听/录音”的状态。
    • 自动归位 (Auto Return)：
      • 当用户松开 FN 键（完成输入）时，悬浮球自动飞回屏幕右侧边缘的初始位置，恢复静止状态。
  • 词汇快速添加 (Quick Vocabulary Add via Orb)
    • 触发：用户右键点击悬浮球。
    • 操作：在弹出的菜单中选择“添加新词”，会出现一个极简的输入框。
    • 流程：用户手动输入词汇 -> 点击“完成”/回车 -> 悬浮球提示“已添加”。
    • 效果：该词汇立即加入本地白名单，下次识别即时生效。
  • 交互式纠错反馈 (Interactive Error Correction)
    • 触发逻辑：当后端的纠错逻辑（LLM 后向纠错或规则引擎）检测到用户刚才输入的语句中存在低置信度词汇或疑似错误时。
    • 视觉提示：悬浮球上会立即出现一个醒目的红色叹号 (!) 图标，提示用户“可能听错了”。
    • 用户操作：
      • 点击叹号：悬浮球展开，展示系统推测的“可能的正确词汇”列表。
      • 选择纠正：
        1. 场景 A (列表中有正确词)：用户点击选中正确的词汇 -> 系统自动将光标前的错误词替换为正确词 -> 同时自动将该词加入本地词库，完成一次无感训练。
        2. 场景 B (列表中无正确词)：用户选择“手动输入” -> 输入正确词汇 -> 确认 -> 系统替换文本 -> 同时自动将该词加入本地词库。
    • 价值：既完成了当前的文本修复，又通过“纠错即训练”的机制，自动丰富了用户的个人词库。
  • 极简配置 (Minimalist Configuration)
    • 无独立设置页：程序不提供任何独立的设置窗口或复杂的 Preference 面板。
    • 右键轻配置：
      • 用户仅需右键点击悬浮球，即可弹出一个简洁的菜单。
      • 菜单仅包含最必要的选项（如：切换语言 Region、选择麦克风源、退出程序）。
    • 设计原则：避免让用户陷入繁琐的参数调整，提供“即装即用”的默认最优体验。

3.4 帮助中心与文档 (Help Center & Documentation)​

  • 全Web化策略：为了保持 APP 客户端的极简体积，所有的支持类内容均不内置在 APP 中。
  • 独立站承载：所有的使用帮助 (Help)、常见问题解答 (Q&A)、产品手册 (User Manuals) 均托管在官方独立站。
  • 跳转机制：APP 内部仅提供跳转入口（链接或按钮），点击后直接唤起系统浏览器访问独立站对应页面。

3.5 用户引导与首次体验 (Onboarding & First Experience)​

  • 启动引导 (Onboarding Flow)：
    • 首次打开：用户首次安装并打开软件时，系统自动弹出引导界面。
    • 强制流程：
      • 登录/注册页：直接展示登录注册选项（见 7.1）。
      • 区域选择：用户选择英语区域（Locale）。
      • 权限授予：麦克风权限、辅助功能权限（用于模拟键盘输入）。
    • 完成引导：配置完成后，引导界面消失，悬浮球 (Orb) 首次从屏幕边缘滑入。
  • 悬浮球初次亮相：
    • UI 展示：右侧边缘中间出现带 Logo 的悬浮球。
    • 动效：
      • 静态呼吸：在静止待机状态下，悬浮球保持微弱的呼吸动画，提示“我在这里，随时待命”。
      • 动态旋转：当进行初始化加载或后台处理时，悬浮球展示动态旋转动画。
    • 功能发现：引导用户右键点击悬浮球，展示“添加词汇”和“快速设置面板”入口。

3.6 用户数据展示与管理 (User Data & UI)​

  • 账户管理界面 (AccountManagementView)：
    • 数据加载：界面打开时，通过 viewModel.loadAccountInfo() 从 AuthenticationManager 异步获取当前登录状态和详细用户信息。
    • 个人信息展示：
      • 头像：显示用户名首字母 (Initials)，简洁统一。
      • 基础信息：邮箱地址 (Email)、用户 ID（脱敏处理，仅显示前 8 位）。
      • 订阅状态：展示订阅等级徽章（Free/Basic/Pro/Plus）及订阅到期时间。
    • Token 用量监控：
      • 数据源：通过 BillingStore 从后端 billing-summary API 实时拉取。
      • 展示维度：订阅 Token 余额、License Token 余额、本月已使用量统计。
    • 操作入口：
      • 提供“升级订阅”和“管理订阅”按钮（跳转至订阅详情页）。
      • 提供“修改密码”按钮（弹出 ChangePasswordView 进行密码修改）。
    • UI 风格：深色主题设计，支持多语言本地化 (Localization)。
  • 词汇管理界面 (VocabularyManagementView)：
    • 内容：展示手动添加的词汇列表。
    • 本地存储：加密存储在本地 AppConfigManager.customPhrases 中。
    • 功能：支持词汇的增、删、改及批量导入。

3.7 客户端容错与反馈体系 (Client-Side Error Handling)​

  • 统一错误管理 (ErrorAlertManager)：
    • 机制：采用单例模式统一管理全应用的错误展示。
    • 8大基础错误分类：系统将异常严格归类为以下类型，每种配备专属图标和颜色标识：
      • 权限 (Permission)：麦克风/语音识别/无障碍权限缺失。
      • 网络 (Network)：连接超时、服务不可用。
      • 文件 (File)：读写失败、路径无效。
      • 配置 (Config)：API Key 缺失、配置损坏。
      • 识别 (Recognition)：SFSpeech 引擎内部错误。
      • LLM：模型调用失败、Token 耗尽。
      • 订阅 (Subscription)：订阅过期、支付失败。
      • 未知 (Unknown)：兜底错误类型。
  • 交互与引导：
    • ErrorInfo 结构体：封装错误标题、详细描述、解决方案列表、是否支持重试以及主次操作回调。
    • 快捷调用：提供 showMicrophonePermissionError、showNetworkError 等预定义方法。
    • 操作引导：错误弹窗不仅展示信息，还提供“打开系统设置”、“重试”等行动点 (Call to Action)，直接引导用户解决问题，而非单纯报错。

4. 核心技术流程 (Core Technology)​

4.1 语音转文本处理流程 (Pipeline)​

  1. 第一阶段处理：首先由 SFSpeech + Contextual String + Custom LM 处理纠正一次，输出到内存。
  2. 第二阶段偏置 (In-Memory Bias)：构建一个内存级规则引擎，将用户易错词汇和上下文条件训练为触发规则。
    1. 极速响应：所有匹配与修正操作在内存中仅需 数毫秒 (ms) 即可完成，对用户感知的输出延迟没有任何影响。
    2. 分级偏置体系 (Hierarchical Bias)：为了保证规则逻辑清晰且高效，偏置处理分为三个层级：
      • Level 1 (简单上下文)：基于基础同音字、固定短语搭配的直接修正。
      • Level 2 (复杂上下文)：基于长句逻辑、专业领域术语（如医疗、法律）的条件修正。
      • Level 3 (动态上下文)：结合后续的前向预测结果，动态加载即时规则进行修正。
  3. 预测与上下文更新：系统实时分析当前输入内容的语境话题（如 AI、医疗、法律等）。一旦识别出特定话题（例如检测到用户正在谈论 AI），系统会动态加载该领域相关的易错词汇表（如 Transformer, Token, Embedding）进入 Contextual String，为下一次语音片段的识别提供高权重的偏置支持。

💡 扩展解释：二次偏置与预测 (Second-stage Bias & Prediction)

  • SFSpeech 的局限：苹果自带的 SFSpeech 虽然准确，但对特定领域术语支持有限。
  • 二次偏置 (规则引擎)：这是一个运行在内存中的精密“后处理层”。它不依赖复杂的模型推理，而是依赖预先训练好的高效率规则。
    • 例如：ASR 输出了“云计算”，系统会瞬间扫描三级规则——
    • L1: 检查是否为同音错词；
    • L2: 检查前一句是否提到了“CT影像”。
    • L3: 检查前一句是否提到了“CT影像”。
    • 若规则触发，系统会在毫秒级时间内将其强制纠正为“云胶片”（假设为医疗场景下的特有术语），用户几乎感觉不到修正过程。
  • 向前预测：这是一个动态的话题感知机制。例如，当系统判断用户的话题是“AI 技术”时，它会预判用户接下来极可能使用 AI 相关的专业术语。于是系统提前将“AI 领域易错词表”注入到 Contextual String 中。这样，当用户真的说出这些复杂的专业词汇时，识别引擎已经做好了准备，极大地降低了延迟和错误率。

4.2 ASR 引擎配置 (Apple SFSpeech)​

  • 引擎：Apple SFSpeech
  • 特性配置：
    • Contextual String：用于上下文偏置，硬偏置。支持即时更新，马上生效。容量约 100 个词汇。
    • Custom LM (Custom Language Model)：用于上下文偏置，需要编译后成为 .bin 文件下载。支持 10000+ 以上词汇，支持上下文，支持语音发音的音素（需测试音素是否生效）。
    • TaskHint：设置为 .dictation。
  • 隐私与网络：强制本地运行。除了初次下载模型，核心转录过程不依赖网络。
  • 待定：是否增加标点符号；确认连续流式还是非流式。

4.3 音频模式 (Audio Session)​

  • 框架：AVAudioSession
  • Category：配置为 .record 或 .playAndRecord。
  • Mode：推荐设置为 .measurement 或 .spokenAudio。

💡 扩展解释：.measurement 模式

  • 含义：此模式旨在提供尽可能“纯净”的音频输入。
  • 作用：它会关闭系统自带的自动增益控制 (AGC) 或激进的信号处理（如为了通话清晰而做的重度降噪）。这对 ASR 引擎至关重要，因为 ASR 算法通常希望接收原始声音数据，由引擎内部算法来处理降噪，避免系统预处理导致的声音失真（即笔记中提到的“过度被算法处理”问题）。

4.4 智能分段策略 (Smart Segmentation Strategy)​

为了实现半流式输出的最佳阅读体验，系统采用智能规则算法对文本流进行动态分段。

  1. 预处理 (Preprocessing)：
    1. 执行标点标准化，将所有全角/中文标点（。？！）转换为标准的半角/英文标点（.?!），统一符号空间以确保解析一致性。
  2. 核心逻辑 (Core Logic)：
    1. 采用前向累积策略，以“句子”（强终止符 .?! 界定的单元）为最小颗粒度读入缓冲区，基于以下阈值逻辑进行动态裁决：
      • 聚合模式 (Aggregation Mode)：当缓冲区累积词数 < 20 时，判定为“欠饱和”。系统将忽略当前句尾的强终止符，强制合并下一句，以防止碎片化并维持语流连贯性。
      • 切分模式 (Segmentation Mode)：当缓冲区累积词数处于
      • $$20, 30$$
      • 区间时，判定为“最佳窗口”。系统将在当前句子的强终止符（.?!）处立即执行硬切分 (Hard Split)，并清空缓冲区上屏。
  3. 异常处理 (Exception Handling)：
    1. 熔断/降级机制 (Fallback Mechanism)：若遇到超长难句导致缓冲区单次输入即 > 30 词，系统触发降级策略：放弃寻找强终止符，转而回溯搜索最近的弱终止符（,;:）进行句内软切分 (Soft Split)，以确保单段文本长度符合生理阅读/朗读极限。

5. 语言支持策略 (Language Support Strategy)​

设计哲学：做减法，保精度 (Precision over Quantity) 为了在有限的资源和时间下实现极致的准确率与低运营成本，我们明确不支持市面上 LLM 常见的 100+ 泛语言支持。每一个支持的语言都必须经过复杂的工程调优，因此我们只服务于“精准客户”和“有限的高价值语言”。

5.1 v1.0 版本支持范围 (Current Release)​

  • 单一语种，全区域覆盖：本次发布仅支持英语 (English)。
  • Locale 策略：只要是 Apple SFSpeech 框架支持的所有英语区域 (English Locales)，全部开放支持。
  • 初始化流程 (Initialization Flow)：
    • 强制选择：用户首次打开 APP 时，必须选择精准的英语区域（Region/Locale）。
    • UI 策略：为了简化选择，界面将优先展示前 5 个核心区域，并将其他支持的区域折叠在 "More English Regions" 菜单中。
      • Core Regions (直接展示):
        • 🇺🇸 en-US: 英语 (美国)
        • 🇬🇧 en-GB: 英语 (英国)
        • 🇮🇳 en-IN: 英语 (印度)
        • 🇦🇺 en-AU: 英语 (澳大利亚)
        • 🇨🇦 en-CA: 英语 (加拿大)
      • More English Regions (折叠菜单):
        • 🇸🇬 en-SG (新加坡), 🇳🇿 en-NZ (新西兰), 🇵🇭 en-PH (菲律宾), 🇮🇩 en-ID (印尼), 🇮🇪 en-IE (爱尔兰), 🇿🇦 en-ZA (南非), 🇸🇦 en-SA (沙特), 🇦🇪 en-AE (阿联酋)
    • 资源检测与下载：系统自动检测当前设备是否已安装所选区域的高级语音包。如果缺失，自动引导或触发系统下载相应的 On-device 语音模型，确保本地化运行能力。

5.2 未来语言扩展规划 (Future Roadmap)​

  • 架构预留：程序架构设计需支持多语言扩展（I18n），但在 v1.0 代码层面锁定为英语。
  • 目标语言池 (仅限以下语言)：
    • 日语 (Japanese)
    • 德语 (German)
    • 法语 (French)
    • 意大利语 (Italian)
    • 西班牙语 (Spanish)
  • 边界声明：除上述语言及英语外，暂不计划支持其他语言。我们不做“翻译机”，只做“母语级精听工具”。

6. 痛点分析与解决方案 (Pain Points & Solutions)​

当前存在的问题​

  1. 环境干扰：公共场合、咖啡厅、机场等噪音导致不准确。
  2. 硬件缺陷：采集设备差，蓝牙压缩丢包导致信号不完整。
  3. 算法过度处理：降噪导致失真，产生“幻觉”文本。
  4. 说话人因素：
    1. 口音、语速过快。
    2. 表达习惯、多语言混杂。
    3. 基础能力不好（发音不清）。
  5. 语义识别困难：
    1. 同音字无法识别上下文。
    2. 大量专业术语、自造词汇无法识别。

解决方案关键点​

  • 硬件结合：引入 Aurisper Pin 专用硬件。
    • 解决通用蓝牙耳机的频响范围窄、压缩率高、降噪算法破坏人声特征等问题。
    • 提供 ASR 引擎所需的“高信噪比”且“低失真”原始音频。
  • 软件优化：利用 Contextual String 和 Custom LM 解决专业术语和同音字问题。
  • 本地化：强制本地运行，避免网络丢包和隐私泄露。

7. 后端服务与认证 (Backend & Auth)​

7.1 认证系统 (Authentication System)​

  • 认证平台：Supabase (https://supabase.com/)
  • 支持功能：支持用户首次使用软件在引导界面注册/登录。
    • 认证方式：
      • 邮箱登录：传统的邮箱 + 密码。
      • 第三方登录：Google、Microsoft、Apple*。
      • 注：独立站 (Standalone) 版本不支持 Apple 登录。
  • 详细技术流程 (Detailed Technical Flows)：
    • 邮箱登录流程：
      1. 前端：用户输入邮箱和密码，客户端先进行格式校验。
      2. 验证：校验通过后，将凭证通过 HTTPS 发送至 Supabase Auth 服务进行验证。
      3. 成功回调：验证成功后，服务端返回包含 JWT Access Token 和 Refresh Token 的 Session。
      4. 持久化：客户端将 Token 加密存储到 macOS Keychain 实现安全持久化登录，同时更新本地认证状态。
      5. 初始化：登录成功后，初始化 RevenueCat 订阅服务并同步用户信息到本地状态管理器。
    • 第三方登录流程 (Google/Microsoft)：
      1. 发起：用户点击登录按钮，客户端调用 Supabase OAuth 接口构建授权 URL。
      2. 跳转：唤起系统浏览器跳转至第三方登录页面。
      3. 回调：用户完成验证后，浏览器通过 Deep Link (aurisper://auth/callback) 携带授权码回调至 App。
      4. 换票：Supabase 用授权码向第三方换取用户信息并创建 Session 返回客户端。
    • Apple 登录流程 (App Store 版)：
      1. 发起：客户端生成随机 Nonce 并进行 SHA256 哈希后附加到授权请求中。
      2. 系统验证：系统弹出原生 Apple 登录面板，完成生物识别验证后返回 ID Token。
      3. 验证：客户端将 ID Token 和原始 Nonce 发送给 Supabase 验证签名和防重放，验证通过后完成登录。
    • 用户注册流程：
      1. 输入：用户填写姓名、邮箱、密码并勾选服务条款。
      2. 校验：客户端校验邮箱格式和密码长度（≥8字符）。
      3. 创建：通过校验后调用 Supabase Auth 创建用户账户。Supabase 使用 bcrypt 哈希存储密码。
      4. 业务逻辑：数据库触发器 (Trigger) 自动在业务用户表中创建对应记录并设置默认 Free 等级。
      5. 完成：客户端完成 Session 存储和订阅服务初始化。
    • 修改密码流程：
      1. 输入：用户需输入当前密码、新密码和确认密码。
      2. 校验：校验新密码长度（≥6字符）、两次输入一致且与旧密码不同。
      3. 验证：先通过重新登录的方式验证当前密码正确性。
      4. 更新：验证通过后，调用 Supabase Auth 的用户属性更新接口提交新密码。
      5. 反馈：服务端完成密码哈希更新后返回成功，客户端显示提示并自动关闭窗口。
  • 安全策略 (Security Policies)：
    • 行级安全 (RLS)：使用 Row Level Security 策略保护用户数据。
    • 二次验证：邮箱验证通过 Supabase Auth 与 OAuth JWT Token 二次验证。
    • 安全存储：使用 Keychain 存储敏感 Token。

7.2 LLM (大模型) 平台​

用于大模型训练、文本处理等高级功能（可选，需用户主动触发）。

  • 平台选择：
    • OpenRouter：API 开发文档完善，但非常贵。
    • 第三方平台：OpenAI 兼容平台，转接平台。成本便宜，仅为 OpenRouter 的 10%。
    • API 地址：https://new.aicode.us.com/v1/chat/completions
  • 可选模型：
    • Claude 系列：claude-3-5-haiku, claude-haiku-4-5, claude-opus-4-5, claude-sonnet-4 等。
    • GPT 系列（含预测型号）：gpt-5, gpt-5-codex, gpt-5.1 等。
  • 大模型路由：不同数据处理需求路由到不同模型（如简单的纠错用 Haiku，复杂的语义理解用 Opus）。

7.3 API Token 架构与调度 (API Token Architecture)​

用户使用的 API Token 在订阅后根据对应等级指定配额限制，系统通过 Supabase 实现复杂的 CRUD 和调度逻辑。

  • 用户使用流程 (Request Flow)：
    • 请求发起：客户端发起 LLM 请求，携带 JWT Access Token 发送至 Supabase Edge Function。
    • 鉴权与定级：服务端验证 JWT，提取用户 ID，查询 users 表获取订阅等级（Free/Pro）以确定可用模型和月度配额（如 Free 100 次）。
    • 配额检查：检查本月已用次数。若超限，返回 429 错误及升级提示。
    • Token 筛选：从 api_tokens 表中筛选状态正常、未过期且未超限的 Token。
      1. 策略：按 priority（优先级）和 quota_used（已用量）排序，同优先级随机选择以实现负载均衡。
      2. 兜底：若数据库无可用 Token，回退到环境变量默认配置。
    • 调用与重试：使用选中的 Token 调用 OpenRouter。
      1. 自动熔断：若返回 429/401，自动将该 Token 标记为 rate_limited 或 disabled，并触发重试机制。
    • 日志与计费：调用成功后，记录 token 用量和成本至 usage_logs 表，计算用户配额使用百分比。
    • 响应：返回结果，并在响应头中附带配额警告信息（50%/80%/95%/100% 四级告警）。
  • Token 池化与加密 (Pooling & Encryption)：
    • 池化管理：支持同一 Provider 配置多个 Token 形成 Token 池，通过 priority 字段实现主备切换或加权分流。
    • 加密存储：API Key 入库前进行加盐混淆。
      • 算法：Base64(原始Key + JWT_SECRET前8位 + 后8位)。
      • 脱敏：管理接口仅返回脱敏后的 Key（显示前8后4位），完整 Key 仅在 Edge Function 内部解密使用。
    • 权限隔离：通过 RLS 策略，限制仅 manager 角色可查看和管理 api_tokens 表。
  • 轮询与负载均衡 (Polling & Load Balancing)：
    • 系统维护 api_tokens 表，字段包含 provider, priority, quota_limit, quota_used, status, expires_at。
    • 每次调用更新 quota_used，一旦达到上限，自动置为 rate_limited。
  • 健康检查 (Health Check)：
    • 实时被动检查：API 调用遇错（429/401）即时标记 Token 异常。
    • 主动定期检查：依赖后台 Cron 任务扫描（见 7.4）。
    • 手动干预：管理员可通过 token-management API 重置 Token 配额或状态。

7.4 后端异常检测与自动化运维 (Backend Anomaly Detection & Ops)​

  • 异常检测服务 (detect-anomalies Service)：
    • Cost Anomaly (成本异常检测)：
      • 单次请求成本 > $5 或 24小时总成本 > $500 -> Critical。
    • Usage Pattern Anomaly (使用模式异常检测)：
      • 单用户 1小时请求 > 500 次 或 1秒并发 > 5 次 -> Critical。
      • 单用户 1小时请求 > 100 次 -> Warning。
    • Quota Abuse (配额滥用检测)：
      • 分析 usage_logs，若 Free/Basic 用户实际用量超过配额 150%，生成 QUOTA_ABUSE 告警。
    • Token Health (Token 健康检测)：
      • 耗尽检测：Token 池无可用 Token -> Critical。
      • 过期检测：expires_at < NOW (Critical) 或 7天内即将过期 (Warning)。
      • 冗余度检测：Active 状态 Token 仅剩 1 个 -> Warning。
    • 机制要求：
      • 告警去重：同一类型异常在一定时间内不重复触发。
      • 动态阈值：系统根据历史数据动态调整异常触发阈值。
  • 自动化运维与告警 (Auto-Resolve & Notification)：
    • 告警通知：
      • 若存在 Critical 级别异常，系统构建通知记录并写入 notifications 表。
      • 邮件支持：notifications 表的 channel 字段支持 email，后台对接 Resend 发送邮件通知管理员。
    • 自动解决 (Auto-Resolve)：
      • 禁用无效 Token：对于 token_exhaustion 或已过期异常，自动将对应 Token 状态更新为 disabled。
      • 滥用记录：对于 rate_limit_abuse 类型，写入 user_warnings 表但不自动封禁，留给人工审核。
      • 日志记录：所有自动操作均记录操作类型、时间戳和解决方案描述。
  • 定时任务 (Cron Job: cron-anomaly-check)：
    • 频率：每小时 (Hourly) 自动执行。
    • 流程：验证调用权限 -> 执行 runAnomalyDetection -> 发送通知 -> 执行 autoResolveAnomalies -> 写入 cron_logs 审计。

8. 软件分发与生命周期 (Distribution & Lifecycle)​

8.1 下载与分发流程 (Download & Distribution)​

  • 官方网站功能 (Official Website)：
    • 核心入口：用户可通过官网进行软件下载、订阅计划选择、硬件购买 (Aurisper Pin)、查阅文档（隐私政策、帮助文档、产品介绍）。
    • 分发架构：
      • 存储：软件安装包 (.dmg) 存储在 Cloudflare R2 Bucket 中，利用其高可用性和低成本优势。
      • 全球加速：配置 Cloudflare CDN 支持全球范围的高速下载。
      • 打包格式：macOS 版本统一采用 DMG 打包。
      • 签名验证：分发文件均经过 EdDSA 签名，确保文件完整性和来源可信。
  • App Store 分发：
    • 流程：用户点击下载 -> Apple 服务器验证 Apple ID -> 分发经 Apple 签名和公证的应用包 -> 自动安装至 /Applications。
    • 优势：由 Apple 统一管理安全验证、增量更新和版本控制。
  • 官网独立站分发 (Standalone)：
    • 请求重定向：用户点击下载，请求发送至 Cloudflare Worker (download-redirect)。
    • 版本控制：Worker 将 /latest.dmg 302 重定向到 Cloudflare R2 存储桶中的具体版本文件（如 Aurisper-1.2.0.dmg）。
    • 安全机制：
      • 安装：用户拖拽安装。
      • 首次运行：macOS Gatekeeper 验证 Developer ID 签名 和 Apple 公证 (Notarization) 状态。

8.2 软件更新机制 (Update Mechanism)​

  • App Store 版本：
    • 机制：完全依赖 App Store 后台。系统定期检查，自动推送增量或全量更新包，替换旧版本。
    • 代码处理：通过条件编译 #if STANDALONE_VERSION 排除 Sparkle 组件。
  • 官网版本自动更新 (Sparkle Framework)：
    • 架构：Cloudflare R2 + CDN + Sparkle。
    • 初始化：应用启动时初始化 SPUStandardUpdaterController，延迟 5 秒后检查更新。
    • 检查源：请求 https://aurisper.com/download/appcast-standalone.xml。
    • 逻辑：解析 XML 中的 sparkle:version (Build Number) 与本地比对。
    • 手动/自动：支持用户在“帮助”菜单手动检查更新，也支持后台静默自动检查。
    • 交互：
      • 发现新版本 -> 弹出更新对话框（展示 HTML 版本说明）。
      • 用户确认 -> 下载新版 DMG。
    • 安全验签：下载完成后，Sparkle 使用 EdDSA 公钥 验证 sparkle:edSignature，确保文件来源可信且完整。
    • 安装：自动挂载、替换应用并重启。

8.3 文件管理​

  • 保存位置：配置文件、训练文件、临时文件均保存在系统的应用文件夹。
  • 数据迁移：系统升级或重装后，自动提取前一版本的配置，无需重新配置。

8.4 卸载流程​

  • 支持一键卸载，删除所有文件和系统配置。
  • 需讨论：是在网站提供卸载程序，还是在 APP 管理界面提供卸载功能。

9. 商业模式与竞争 (Business & Competition)​

  • 竞争对手：Wisprflow, Typeless
  • 性能指标：输出延迟需保持在 300ms 以内。
  • 付费模式：支持 Free、Pro、Plus、Bundle、AuriPin 等多层级订阅。

9.1 双轨订阅支付系统 (Dual-Track Subscription System)​

系统支持官网（Shopify）和 App Store（In-App Purchase）两套独立的订阅与支付体系。

  • 订阅周期管理：
    • 过期提醒：
      • 当用户订阅时间不足或即将过期时，系统通过 Email 邮件 和 APP 内弹窗/横幅 发送续费提示。
    • 退款支持：
      • 支持用户对购买或订阅的商品申请退款，需符合相应的退款政策（App Store 遵循 Apple 政策，官网遵循自定义政策）。
  • A. 官网订阅流程 (Shopify + PingPong)：
    • 下单：用户在 Shopify 官网选择计划，通过 PayPal 或信用卡支付。
    • 支付处理：后台走 PingPong 第三方收款（降低手续费）。
    • 权益开通：
      • PingPong 支付成功 -> 发送异步通知至 Cloudflare Worker。
      • 验签：Worker 验证签名（Salt + 参数字典序 SHA256）及订单幂等性。
      • 处理：识别订阅类型，通过邮箱匹配用户。
      • 履约：调用 Supabase upgrade_user_subscription 函数更新用户等级和过期时间。
      • 通知：记录订单至 pingpong_orders 表，通过 Resend 发送确认邮件。
    • 周期管理：由 Shopify 统一管理续费周期。
  • B. App Store 订阅流程 (IAP + RevenueCat)：
    • 展示：客户端调用 RevenueCat SDK 获取 Offerings 并展示。
    • 支付：唤起 App Store 原生支付（Face ID/Touch ID 验证）。
    • 权益开通：
      • 支付成功 -> RevenueCat 服务端发送 Webhook 至 Supabase Edge Function。
      • 验证：Function 校验 Webhook Token 合法性。
      • 处理：根据 entitlement_id 确定等级，更新 users 表 tier 字段。
      • 记录：写入 subscription_events 表，并向用户钱包充值对应 Token（检查幂等性）。
    • 同步：客户端通过 PurchasesDelegate 回调实时刷新本地权限状态。
    • 周期管理：由 RevenueCat 代理管理 App Store 的复杂订阅周期。

10. 安全、隐私与合规 (Security, Privacy & Compliance)​

核心原则：隐私第一 (First Principle) 系统架构设计致力于消除每一个非必须的互联网连接点，实现最大化的本地化运行。

10.1 数据本地化与“不上云” (Data Localization & No Cloud)​

  • 脱网运行：用户在使用核心功能（语音转文字）时，数据完全不上网，支持完全离线（Airplane Mode）运行。
  • 无云端存储：没有云端服务器存储用户的语音音频或转录后的文本内容。
    • 无管理风险：因为没有云端数据，运营方不存在“管理”用户数据的权限，也就不存在查看、滥用或泄露用户数据的可能性。
  • 非必要不联网：坚决消除非必要的网络请求，确保本地环境的封闭性。

10.2 账号权限 (Account & Auth)​

  • 仅用于授权：账号系统仅用于验证用户的 License（购买状态）和权限等级。
  • 数据隔离：账号系统与用户产生的内容（语音/文本）完全隔离。

10.3 智能训练策略：依赖递减与成本控制 (Smart Training & Cost Control)​

我们的训练策略旨在解决“隐私”、“精度”与“成本”的三角平衡。通过依赖递减模型，实现极低的长期运营成本。

  • 模式 A：默认阶段性训练 (Default Phased Training) - 推荐模式
    • 原理：利用大模型作为“助教”，帮助本地模型快速“毕业”，随后切断联系。
    • 密度测算 (Density Calculation)：系统会根据用户的使用密度（每日输入时长、修正频率）自动测算训练周期。
      • 高频用户：可能仅需 3-7 天的密集训练即可完成本地化适配。
      • 低频用户：训练周期相应延长，但总数据吞吐量保持在低位。
    • 毕业即脱网：当系统判定本地规则库（Level 1 & 2）的覆盖率达到 98% 以上时，自动停止数据回传，转为完全脱机运行。
    • 后期维护：毕业后，系统仅接受少量的“程序主动提示补充”（自动发现的新词冲突）和用户的“手动添加”，几乎零成本运行。
  • 模式 B：长期在线训练 (Continuous Online Training) - 可选模式
    • 适用人群：不在乎隐私数据交换，极度追求实时热词更新（如科技新闻工作者）的用户。
    • 知情同意 (Informed Consent)：在充分、明确的隐私风险告知（弹窗+确认）后，用户可选择保持长连接。
    • 功能：允许系统持续调用大模型能力，实时学习最新的网络热词和复杂语法结构。
  • 成本递减效应 (Cost Reduction)：
    • 战略上，对大模型的依赖是从初期的重度迅速衰减为后期的极轻度甚至零。
    • 这使得即便拥有大量用户，我们的 Token 消耗（运营成本）也不会随用户数线性暴涨，从而建立起相对于竞争对手（持续依赖云端）的极低成本壁垒。

10.3.1 闭环自我进化训练流程 (Closed-Loop Self-Evolution Training Flow)​

为了在保护隐私的前提下实现极致精准，系统引入了一种“合成数据对抗训练”机制。该机制通过互联网调取云端能力生成训练素材，但训练和结果应用完全在本地闭环。

  • 流程详解：
    • 用户原始输入 (User Seed Input)：以用户已确认正确的历史输入文本或手动添加的关键词作为种子。
    • LLM 上下文生成 (Context Generation)：调用云端 LLM，基于种子词生成大量符合用户说话习惯的个性化上下文语句（例如：针对“Aurisper”，生成“请打开 Aurisper 设置”、“Aurisper 的识别率很高”等句子）。
    • TTS 语音克隆与输入 (TTS Cloning & Input)：调用云端高保真 TTS（Text-to-Speech）引擎，克隆用户声音或使用标准发音，将生成的上下文语句转换为音频流，模拟真实语音输入。
    • ASR 训练与验证 (ASR Training & Validation)：将 TTS 生成的音频流送入本地 SFSpeech ASR 引擎进行识别。
    • 易错词提取 (Error Extraction)：对比“LLM 生成的原始文本”与“ASR 输出的识别文本”，利用 LLM 分析差异，精准提取出 ASR 容易听错的词汇对（如：将 "Aurisper" 误听为 "Whisper"）。
    • 二次筛选 (Secondary Filtering)：对提取出的易错词进行置信度过滤，剔除偶发错误，保留高频顽固错误。
    • 写入词表 (Vocabulary Update)：将最终筛选出的易错词和纠正对，自动添加到用户的自定义上下文词汇表 (Custom Contextual Strings) 中。
  • 价值：这一流程实现了无需用户朗读即可完成针对性训练，极大提升了对生僻词、专业术语的识别率，且随用随强。

10.4 场景化专业库训练框架 (Scenario-based Specialized Libraries)​

为了保证低成本下的高精准度，我们放弃“通用大模型”的全能路线，转而采用“小而精”的场景化专业库策略。

  • 预置专业库 (Pre-built Libraries)：
    • 针对不同用户画像（如：医疗、法律、编程、金融），预先准备好经过清洗的专业词汇规则库。
    • 低模型消耗：这些库基于规则和轻量级统计模型，而非昂贵的生成式模型，运行时资源占用极小。
  • 持续迭代机制 (Iterative Refinement)：
    • 云端聚合：通过“模式 B”用户贡献的脱敏数据，不断在云端迭代优化各专业库的质量。
    • 下发更新：将优化后的规则库定期下发给所有用户（包括脱网用户，通过APP更新或离线包），让所有用户享受模型迭代的红利，而无需自己消耗数据去训练。
  • 效果：用户选择了“医疗场景”，即可立即获得该领域 99% 的专业术语识别能力，无需从零训练，既保护了隐私，又极大地降低了冷启动成本。

10.5 合规性​

  • 数据标准：由于数据主要滞留本地，天然符合多数高敏感度合规要求（如 GDPR/HIPAA 的本地化处理部分）。
  • 纯本地修正机制：系统不提供云端 LLM 润色功能，所有文本修正（纠错、调整）完全在本地运行，杜绝将文本内容传输至第三方服务的风险。

11. 硬件扩展与高级功能 (Hardware & Advanced Features)​

11.1 Aurisper Pin：混合算力流水线 (Hybrid Processing Pipeline)​

$$Roadmap Notice$$

：Aurisper Pin 硬件计划于 2026 年 3 月 发布。v1.0 软件不需要支持以下硬件连接与专属算法功能，此部分仅作为未来架构扩展的说明。

Aurisper Pin 采用了工程化、流水化的设计哲学，通过明确的**“端云协同”（端指 Pin，云指 Host 设备）**策略，最大化利用各端优势，实现低成本与高性能的完美平衡。

11.1.1 声音采集：高规格源头 (High-Spec Acquisition)​

  • 双麦克风阵列 (Dual-Mic Array)：
    • Mic 1 (Directional)：指向性麦克风，专注拾取佩戴者口部语音。
    • Mic 2 (Omnidirectional)：全向麦克风，负责采集环境背景噪音。
  • 高采样标准：前端保持 48kHz 采样率 / 24bit 深度 的录音规格，最大化保留原始声学信号的动态范围，为后续线性算法提供充足的信息量。

11.1.2 硬件端处理：纯线性与轻量化 (Pin-Side: Linear Only)​

  • 策略：只做线性处理，不做非线性/AI 处理。
  • 处理流程：
    • 线性计算 (Linear Algorithm)：对两路 48K 信号进行波束成形 (Beamforming) 和线性降噪，实现物理层面的指向性拾音，确保只拾取说话人的声音，同时保留非线性部分的背景噪音（不做破坏性消除）。
    • 信号合并与降采 (Merge & Downsample)：处理后的信号合并为单声道，并降采样至 16kHz / 16bit（符合人声语音识别的标准频宽）。
    • 编码传输 (Encoding & TX)：使用 LC3 编码器（低延迟、高音质）对 16K 信号进行压缩，通过 BLE (低功耗蓝牙) 稳定传输至 Host 端（macOS/iOS）。
  • 设计理由 (Design Philosophy)：
    • 如果在 Pin 端强行上非线性 AI 算法，将带来毁灭性的多米诺骨牌效应：硬件成本剧增、功耗暴涨、体积重量失控、佩戴舒适度下降。Aurisper Pin 坚持做“轻量级采集终端”，而非“笨重的计算终端”。

11.1.3 软件端处理：重度 AI 降噪 (Host-Side: AI & Non-linear)​

  • 策略：利用 Host 端 (Mac/iPhone) 的强大算力进行非线性精修。
  • 处理流程：
    • 接收与解码 (RX & Decode)：Host 端接收 BLE 信号并解码为 16K/16bit PCM 音频。
    • 非线性 AI 降噪 (Non-linear AI Denoising)：利用 MacBook (M系列芯片) 或 iPhone (A系列芯片) 的 NPU，运行复杂的深度神经网络降噪模型。
    • SFSpeech 前处理 (Pre-processing)：此时声音尚未进入 ASR 引擎。在此阶段，算法会精准去除残留的非线性噪音（如键盘敲击声、风噪），同时进行增益补偿。
    • 最终识别 (Recognition)：处理后的纯净语音送入 Apple SFSpeech 引擎进行转录。
  • 优势：
    • 算力溢出：Mac/iPhone 处理 16K 音频的 AI 算法简直是“杀鸡用牛刀”，毫无压力，且电量充沛。
    • 位置无关性：声音一旦数字化离开麦克风，在哪里处理效果都一样。在 Host 端处理完全不影响音质。
    • 配合度：在 Host 端可以根据 SFSpeech 的实时反馈微调降噪力度，避免“过度处理”切掉人声尾音，从而保证识别率。

11.1.4 总结：流水线优势 (Pipeline Benefits)​

通过这一流水线设计，我们实现了：

  1. Aurisper Pin：极低功耗、极致轻便、低成本 BOM，佩戴无感。
  2. Host 软件：利用过剩算力，实现好莱坞级别的降噪效果。
  3. 系统整体：以最低的综合成本，达到了行业顶级的语音识别准确率。

11.2 多设备同步​

  • 同步媒介：如果没有云服务，尝试通过 Aurisper Pin 来同步 iOS 和 macOS 之间的模型数据。
  • 机制：需设计具体的同步机制。

11.3 离线工作模式​

  • 最小服务清单：
    • 语音转文本服务（必须可用）。
    • 本地文本修正（必须可用）。

11.4 专业词库管理 (Vocabulary Management)​

  • 批量管理与导入 (Bulk Management)：
    • 入口：在悬浮球右键菜单或软件设置中提供“自定义词汇”管理界面。
    • 操作：支持用户在文本框中批量粘贴词汇。
    • 格式：支持通过标点符号（逗号/顿号）或空格自动识别并分割词汇。用户也可以直接手动输入添加。
    • 去重检查 (De-duplication)：系统在导入时自动检查本地已存在词汇，跳过重复项，仅添加新词，并反馈添加结果（成功数量/重复数量）。
    • 作用：快速建立个人或行业专属词库。
  • 功能包含：训练、导入、匹配、修剪。

11.5 第三方兼容性​

  • 兼容检测：如果第三方软件也占用了 Fn 键，需要有冲突处理机制。